La douloureuse question des attributs et de la défense du français
Maël Reboux, de la Communauté d’agglomération de Rennes Métropole, pose la série de questions suivantes.
J’ai une question en relation avec ce billet :
La question (que l’on me pose de plus en plus fréquemment) :
1. Vu que je détiens / suis producteur de certaines données qui entrent dans le champ de INSPIRE, je dois en faire la diffusion.
==>oui
2. Si des spécifications de données existent pour une de ces données, je dois diffuser des données qui s’y conforment.
==>oui, mais dans le délai rappelé dans le billet référencé (2 à 7 ans)
3. Dois-je conformer le nom de mes attributs (champs) afin qu’ils soient identiques à ce qui est indiqué dans les documents de spécification ?
==>il faudra bien, c’est le prix de l’interopérabilité
Exemple pour une couche de point d’adresses : dois-je obligatoirement avoir un champ qui se nomme « GeometrySpecificationValue » (précision sur la position du point d’adresse : postalDelivery / building…) ?
==> oui, au moins dans la base de données afin qu’il soit correctement transporté dans les services WFS.
Question emboîtée : ce champ doit-il contenir des valeurs en anglais ? ou en français ?
postalDelivery / délivrance postale ?J’aurais tendance à dire oui aux 2 questions mais je viens vers vous pour en savoir plus.
==> Officiellement, la Commission européenne soutient qu’il ne s’agit pas de l’anglais (soyons honnête, aucun anglais ne reconnaîtrait cette suite de caractère pour sa langue), mais d’une formulation « neutre linguistiquement » pour les dialogues entre machines. Nous n’avons pas réussi à faire évoluer cela. Nous avons obtenu la traduction des listes de codes, mais pas des valeurs que ces codes peuvent prendre. C’est donc ce champ « neutre linguistiquement » qui doit être dans la base, c’est lui qui permettra l’interopérabilité et les services en réseau avancés. Pour autant, on n’est pas obligé de le montrer tel quel à tout le monde, et au contraire ne montrer via l’interface d’affichage qu’un terme français.
Précisions : GeometrySpecificationValue renvoie, en français, à « Spécification géométrique » et est défini ainsi : « Information déterminant la spécification utilisée pour créer ou dériver cette position géographique de l’adresse ».
postalDelivery est une valeur possible de l’attribut GeometrySpecificationValue. Sa traduction serait plutôt « point de délivrance postale », mais il est vrai que nous n’avons pas encore de traduction officielle française.
C’est déjà assez compliqué, il me semble important de se rapporter systématiquement aux traductions et définitions légales pour l’interopérabilité sémantique (ici, point 5.4.2 page 39 du Règlement Interopérabilité n° 1089/2010 du 23 novembre 2010 pour l’attribut et point 9 page 18 du Règlement Listes de codes n°102/2011 du 4 février 2011)
Tags: données, INSPIRE, règlement, règles, spécifications
31 mai 2011 à 14:01
Merci pour la réponse… que je craignais.
Cela implique qu’il va nous falloir disposer d’une sorte de base de données de correspondance de tous ces termes. Pour permettre une correspondance automatique. Qui est partant ?
Une question subsidiaire : faut-il que le nom des champs respecte la casse de la spécification ?
6 juin 2011 à 9:39
Les négociateurs français étaient seuls à défendre ce codage en alpha-numérique (qui permet plus facilement le multilinguisme). Bref, nous n’avons pas pu tenir. Comme nous avons beaucoup travaillé sur la traduction des spécifications de l’annexe I, je suis d’accord pour aider. Peut-être cela devrait-il être conduit sous l’égide du CNIG (pour la validation finale)?
La casse est contrainte (si j’ai bien compris, à contrôler)
10 juin 2011 à 15:47
Je reviens sur la question de l’obligation de renommer les champs des bases de données :
« Question : Exemple pour une couche de point d’adresses : dois-je obligatoirement avoir un champ qui se nomme « GeometrySpecificationValue » (précision sur la position du point d’adresse : postalDelivery / building…) ?
Réponse : ==> oui, au moins dans la base de données afin qu’il soit correctement transporté dans les services WFS. »
En réalité, rien n’oblige à modifier le nom des champs dans sa base de données, l’important est de pouvoir générer facilement le contenu du champ attendu par le format d’échange, et de l’identifier clairement dans le flux GML généré par le WFS avec l’intitulé attendu par la norme.
… C’est l’avantage de l’interopérabilité.
11 juin 2011 à 15:30
Merci François de ce complément. J’ai souvent tendance à mettre en avant la solution d’adaptation des bases, alors que la transformation lors de la diffusion est tout aussi valable.
La clé de choix est, la plupart du temps, dans la fréquence de mise à jour, et donc d’export. Lorsqu’une base évolue peu, il est peu utile de la mettre en forme INSPIRE et la mise en place d’une moulinette d’export est rentable. Par contre, si la mise à jour est fréquente, donc la fabrication de l’export aussi, l’adaptation des règles en interne est probablement rentable à l’occasion d’une refonte du système d’information local (avant 2018).
17 juin 2011 à 10:22
@François Robida
« En réalité, rien n’oblige à modifier le nom des champs dans sa base de données, l’important est de pouvoir générer facilement le contenu du champ attendu par le format d’échange, et de l’identifier clairement dans le flux GML généré par le WFS avec l’intitulé attendu par la norme. »
Bien sûr mais, actuellement, je suis assez dudibatif sur les performances d’une transformation à la volée de tables entières + mappage des listes de valeurs vers l’anglais.
A mon avis, on ne coupera pas à générer une BD version INSPIRE qui servira de support aux flux OGC.
Qu’en pensez-vous ?
20 juin 2011 à 12:53
« A mon avis, on ne coupera pas à générer une BD version INSPIRE qui servira de support aux flux OGC. »
A lier éventuellement, puisque producteur de données il y a, à l’architecture du système de production, qui peut employer:
une base de production = les nouveautés uniquement
une base de consolidation = l’ensemble des données produites, les données externes
une (des) bases de diffusion
…
Du boulot (et donc les compétences afférentes) en plus, mais des séparations claires dans le si et une sécurité accrue.
my 2 cents!
22 juin 2011 à 10:22
La solution évoquée par n314 est en effet envisagée, celle de François aussi, et depuis vendredi dernier on me reparle, en plusieurs endroits, de registres. Ces derniers étaient envisagés au départ par les architectes d’INSPIRE mais ont heurté à pleine vitesse un iceberg juridique (=le mode de gouvernance) et ont coulé à pic, au moins dans leur forme originale.
Le problème est que, si je vois en gros ce qu’est un registre et ce que cela apporte en théorie, j’ignore comment cela fonctionne concrètement dans une infrastructure décentralisée. On a donc un problème d’usage, de maîtrise d’oeuvre et de gouvernance (nationale)…
Mais quand des gens d’origine différentes posent en même temps la même question, c’est que le temps est venu de la traiter… Du travail pour le BIG?